Fast alle Hacker weltweit machen begeistert bei dem Projekt distributed.net mit. Ich denke wir sollten uns eine kritischere Einstellung zu diesem Projekt aneignen.

Das distributed.net Projekt

distributed.net ist eine Aktion, um zu beweisen, da▀ die heute eingesetzten Verschlⁿsselungsverfahren unsicher sind. PrimΣr wendet sich distributed.net gegen die Algorithmen DES und RC5. Der Beweis, das diese Verschlⁿsselungssysteme nicht hinreichend sicher ist, soll dadurch erreicht werden, da▀ einzelne, mit DES bzw. RC5 verschlⁿsselte Nachrichten, entschlⁿsselt werden. Dies geschieht, indem einfach alle Schlⁿssel durchprobiert werden, bis beim entschlⁿsseln eine sinnvolle Nachricht herauskommt. Ein nicht sonderlich intelligentes Verfahren, aber vermutlich bei einigen Verschlⁿsselungsalgorithmen die einzige M÷glichkeit, an den Inhalt einer verschlⁿsselten Nachricht zu kommen.

Da ein einzelner Rechner sehr lange brauchen wⁿrde, um alle Schlⁿssel durchzuprobierten, mⁿssen mehrere Rechner sich die Arbeit teilen. Und da es sich um sehr viel Arbeit handelt, mⁿssen sich sehr viele Rechner die Arbeit teilen. Um diese Arbeitsteilung m÷glichst komfortabel zu machen, hat distributed.net eine Software entwickelt, die oft als rc5des bezeichnet wird.

Im groben sieht das Prinzip dieser Software so aus: Jeder, der teilnehmen will installiert eine sogenannte Client-Software auf seinem Computer. Dieser rc5des Client ist fⁿr sehr viele unterschiedliche Computer und Betriebssysteme erhΣltlich. Der Client verbindet sich dann zu einem distributed.net Server und meldet sich zum Arbeitsantritt. Er bekommt dann einen Block Schlⁿssel zugeteilt, die er auszuprobieren hat. Der Client probiert dann die im zugewiesenen Schlⁿssel durch, was einige Minuten bis viele Stunden dauern kann. Dabei lΣuft er im Hintergrund mit niedriger PrioritΣt, so da▀ er die normale Arbeit an dem Computer, auf dem er lΣuft, kaum behindert. Praktisch arbeitet er nur, wenn der Computer nichts anderes zu tun hat. Den Windows Client kann man sogar so konfigurieren, da▀ man nicht sehen kann, da▀ er lΣuft.

Wenn der Client mit seinem Block Schlⁿssel durch ist, meldet er sich wieder bei einem der distributed.net Server, sagt da▀ er fertig ist und fordert einen neuen Schlⁿsselblock an. Um die Verbindung zum Server auch aus stark gesicherten Netzwerken zu erm÷glichen, verfⁿgt der rc5des Client zum einen ⁿber die M÷glichkeit die Daten ⁿber allerlei esoterische Wege an Firewalls vorbeizutunneln, zum anderen gibt es einen Proxyserver, mit dem man auch an Firewalls und privaten IP-Adressbereichen vorbei arbeiten kann.

Was distributed.net da macht ist also ganz sch÷n spannend: Die eh nicht genutzte Rechenzeit auf tausenden Rechnern weltweit fⁿr einen guten Zweck einsetzen. Meta-Computing wird das ganze auch genannt. Eins ihrer Mottos ist "Cryptographie sicherer machen, indem man sie bricht". Dadurch, da▀ bewiesen wird, da▀ manch Verschlⁿsselungssysteme gebrochen werden k÷nnen, hoffen sie, die Industrie dazu zu bewegen, nur noch sicherere Algorithmen einzusetzen.

Probleme mit distributed.net

Also alles sch÷n und gut? Nein, meiner Meinung nach ist distributed.net b÷se. Die Ziele, die distributed.net anstrebt sind sicher ehrenwert, aber die Methode die sie dazu anwenden ist falsch. Und das falsche lΣ▀t sich in einem Satz zusammenfassen: Die Software ist nicht im Quelltext erhΣltlich.

Warum das ein Problem sein soll? Jedem, der sich nochmal die Features des rc5des Clients oben ansieht, sollte klar sein warum das so ist. Da wird verlangt eine Software zu installieren, die mit irgendwelchen Servern im Internet kommuniziert und dabei in der Lage ist, an den meisten Firewalls und anderen Sicherheitssystemen vorbei Daten zu ⁿbertragen. Diese Software ist obendrein auch noch in der Lage, sich zumindest unter Windows einigerma▀en wirkungsvoll vor dem Benutzer zu verstecken.
Und eine solche Software soll man installieren, ohne den Quellcode zu haben, um nachzuschauen, was dieses Programm wirklich macht?

M÷glich wΣre doch beispielsweise, das das Programm ungefragt und unentdeckt Informationen aus dem eigenen Computer herausschafft. Oder auch schlichtweg, da▀ es bei der Angabe, wer da rechnet manchmal etwas pfuscht. Schlie▀lich gibt es einen bedeutenden Geldpreis fⁿr den, der den richtigen Schlⁿssel findet. Woher soll ich wissen, da▀ das Programm sich bei mir meldet und den Schlⁿssel nicht einfach klammheimlich 'rausschmuggelt und ich nichts von dem Gewinn abbekomme.
Und selbst wenn man davon ausgeht, das die Programmierer von rc5des integere Menschen sind, wer stellt sicher, da▀ sie keine Fehler bei der Programmierung gemacht haben, die dazu fⁿhren, da▀ der rc5des Client von dritten zu irgendwelchen b÷sen Zwecken eingesetzt wird?

Obskures SicherheitsverstΣndnis

Warum gibt distributed.net den Quellcode fⁿr ihren Client nicht heraus? Erstaunlicherweise wird das mit "der Sicherheit" begrⁿndet. Wenn jeder den Quellcode fⁿr den rc5des Client hΣtte, k÷nnten b÷se Menschen rc5des so modifizieren, da▀ er gar nicht die ihm zugeteilten Schlⁿssel ausprobieren wⁿrde, sondern sie einfach als ausprobiert zurⁿckmelden wⁿrde, ohne lange 'rumzurechnen. Das wⁿrde natⁿrlich wesentlich schneller gehen, so dieser b÷se Mensch in der Statistik wesentlich weiter oben erscheinen wⁿrde. Er hΣtte allerdings nie die Chance zu gewinnen, da er ja nicht den richtigen Schlⁿssel finden kann, weil er gar nicht ⁿberprⁿft, ob unter den ihm zugeteilten Schlⁿsseln der richtige ist.
Das ganze k÷nnte den Erfolg von distributed.net empfindlich gefΣhrden, denn es wΣre theoretisch m÷glich, da▀ zufΣllig in den dem Betrⁿger zugeteilten Bl÷cken der richtige Schlⁿssel lag. Da dieser die Schlⁿssel ja nicht ausprobiert, sondern sie einfach so als fertig zurⁿckmeldet, wⁿrden sie in der distributed.net Datenbank als erfolglos getestet vermerkt und somit nicht weiter ⁿberprⁿft. Somit hΣtte distributed.net keine Chance, die richtigen Schlⁿssel zu finden.

Die ─ngste, die bei distributed.net vorhanden sind, klingen zunΣchst plausibel und doch sind sie meiner Meinung nach b÷se. Sie sind derartig naiv und f÷rdern eine ungemein falsche Denkweise, da▀ man sie nur als b÷se bezeichnen kann.

Warum? Die Denke der distributed.net Leute beruht auf der der Annahme, es gΣbe "Security by Obscurity". Sie denken, wenn sie das ganze nur undurchschaubar genug machen, in dem sie den Quellcode nicht herausgeben, wⁿrde das ganze sicher werden. Dies ist ein auch in der Industrie sehr verbreiteter Irrglaube. Und dieser Irrglaube ist b÷se, weil er zunΣchst so ungemein einleuchtend klingen kann und daher schon sehr viel Schaden angerichtet hat. Denn praktisch bietet dieser Ansatz kaum zusΣtzliche Sicherheit.

Die Hackercommunity verbringt sehr viel Zeit und Nerven darauf, der Industrie beizubringen, da▀ sie offene Modelle nutzen mu▀, wenn sie wirklich sichere Produkte erstellen will. ▄ber die letzten Jahre haben wir auf diesem Gebiet schrittweise Erfolge erzielen k÷nnen.

Und jetzt gibt es da eine Gruppe daher, die beweisen will, da▀ man bessere Verschlⁿsselung nutzen mu▀ und dabei ihren eigenen Code durch "Security by Obscurity" zu schⁿtzen versucht. Das wirft unser Bemⁿhen, dieses windige Sicherheitskonzept ein fⁿr alle mal zurⁿckzudrΣngen ein ganzes Stⁿck zurⁿck.

Pfuschen auch ohne Quellcode

Das der rc5des Client ohne Quellcode nicht wesentlich sicherer ist, als mit Quellcode, ist ein gutes Beispiel, wie "Security by Obscurity" versagt. Wenn er den Quellcode hΣtte, k÷nnte ein Schuft diesen so modifizieren, da▀ nicht wirklich irgendwelche Keybl÷cke berechnet werden, sondern diese einfach so als fertig gemeldet werden (s.o.). Dafⁿr mⁿ▀te er allerdings in der Lage sein, den hoch optimierten Code des rc5des Clients zu verstehen.

Was fⁿr M÷glichkeiten bleiben einem Schuft, wenn er nicht den Quellcode besitzt? Er kann die Buffer-files, in denen rc5des seine Daten speichert, analysieren und dann zu seinen Gunsten modifizieren. Er k÷nnte auch das Protokoll, ⁿber das der rc5des Client mit dem Server kommuniziert, analysieren und dann ein Programm schreiben, welches sich dem Server gegenⁿber als normaler Client tarnen, ohne jemals etwas zu berechnen.

Was fⁿr unseren Schuft aber sicher am leichtesten wΣre, ist es, den rc5des Client so zu patchen, da▀ er einfach nicht mehr rechnet, sondern nur Bl÷cke als fertig meldet. Um dies zu erreichen mu▀ er nur eine einzige Assembler-Anweisung patchen, nΣmlich die Schleife um die DES-Berechnung. Diese ist aufgrund des stark optimierten Codes in rc5des besonders einfach unter dem Debugger auszumachen. Fⁿr jeden, der sich schon mal ernsthaft an fremdem Code 'rumgepatcht hat, sollte das wirklich kein Problem sein.

Im c4 ist es uns in kⁿrzester Zeit gelungen, diesen Patch durchzufⁿhren. Wenn wir das k÷nnen, k÷nnen andere das auch. Es zeigt sich also, da▀ der rc5des Client auch ohne Quellcode ungemein anfΣllig gegen Manipulationen ist. Das Sicherheitsargument fⁿr die Nichtfreigabe des Quellcodes zieht also nicht.

Was tun?

Mit diesem Sachverhalt ist nicht einfach umzugehen. Generell sind die Ziele von distributed.net ja durchaus unterstⁿtzenswert. Soll man jetzt keine rc5des Clients mehr laufen lassen?
Ich denke, das Ziel darf nicht der Abbruch des distributed.net Projekts sein, sondern die Freigabe des Quellcodes. Um dies zu erreichen sollte man auf die ZugΣnglichkeit von distributed.net fⁿr rationale Argumente hoffen. Es bleibt nur zu hoffen, da▀ man nicht den einen Pfusch-Patch fⁿr rc5des als Argumentationshilfe freigeben mu▀.

Ich kann somit jeden, der einen rc5des Client betreibt, empfehlen, bei distributed.net den Quellcode einzufordern. For the sake of the code.

Doobee R. Tzeck